Testing Playbook

Entry Point: From Company Add/Edit/View or Individual Add/Edit/View screens, users access a "Add Note" or "Add Action" button/modal.

Data Fields Required:

• Note/Action Common: Related To Type, Related To Record ID, Created By, Created Date/Time, Last Modified Date, Modified By, Note Date, Note Category, Note Type (optional per ABC-1960), Note Text, Attachment
• Action Only: Assigned To (defaults to Created By), Assigned To Date, Due Date (renamed from "Action Date" per ABC-1924), Action Category, Action Type, Action Text, Status, Completed Date

Note Date Behavior: Defaults to current date but can be back-dated. Users may record historical notes/actions. This field is required.

Created By Default: Automatically set to current logged-in user. Cannot be changed during creation.

Assigned To Default (Actions): Defaults to the current user (Created By) but can be reassigned during creation.

Entry Point: From Selective Reporting Results (Companies or Individuals), users can bulk-create Notes or Actions applied to all selected records.

Prefixed Text Behavior: Global Notes/Actions automatically prepend origin context. Example: "[Selective Reporting] Your note text here". This aids traceability and prevents confusion about note origin.

Error Handling (ABC-2975): If creation fails on some records, the system does NOT roll back successful records. Instead, it reports a summary: "Created on 45 records, failed on 2 (insufficient permissions)". Users can manually retry failed records.

Duplicate Prevention (ABC-1923): The system prevents creation of duplicate global actions with identical parameters. If user attempts to create the same global action twice, a warning is displayed.

Purpose: Predefined sets of actions that can be bulk-attached to records (Company or Individual). Checklists streamline repetitive task creation and ensure consistency.

Creation Flow: Admin users create checklists with the following attributes:

• Checklist Name: Display name (e.g., "New Company Onboarding")
• Description: Purpose and scope
• Module: Target module (Company or Individual)
• Enabled/Disabled: Toggle availability
• Actions: List of action tasks with future date offsets (e.g., +1 day, +7 days for Due Date calculation)

Attachment Flow: From a Company/Individual record, users select "Attach Checklist" → choose checklist → confirm → system creates all actions with calculated due dates (base date + offset).

Copying Checklists: Admin can copy existing checklists to create variations without manual recreation.

Default Assignee: Actions from checklists default to current user but can be overridden during attachment.

Entry Point: Main Navigation > Notes & Next Actions

Default Filter (Updated per ABC-2005): "Actions Assigned to Me" (previously showed all actions; changed for user-centric task management)

Available Filters:

• Type (Note, Action, Completed Action)
• Related To Type (Company, Individual, Event, Course)
• Related To (string search by record name)
• Assigned To (staff member dropdown)
• Action Due Date (date range picker)
• Status (Open, Complete)

Default Sort: Type ascending (Actions above Notes), then Date descending (newest first)

Display Fields: Type, Related To Type, Related To Name, Created By, Assigned To, Date, Due Date, Status, Last Modified Date, Text preview

View Modal (Read-Only per ABC-1927): Clicking a record opens a modal showing full details. Users cannot edit from this modal; they must use the Edit button to open the edit form.

Pagination: Results paginated (25 items per page default); users can adjust page size.

Export (ABC-1755): Users can export filtered results to Excel or PDF with all visible fields.

Status Values: Actions have two statuses: Open and Complete. Notes do not have status.

Marking Complete: Users can mark actions complete from:

• The Browse All screen (checkbox/button on action row)
• The Edit Action form (Status dropdown set to "Complete")
• The Dashboard widget (Quick Action button)

Completed Action Behavior (ABC-1922):

• Type displays as "Note" throughout the interface
• Status shows "Complete"
• Assigned To and Due Date persist and remain visible for historical audit
• Completed Date automatically captured when status changes to Complete
• Completed actions are excluded from the default "Actions Assigned to Me" filter but can be viewed with custom filters

Edit/Delete Rights on Completed Actions: Creator can still edit completed actions (reopen if needed); assignee cannot edit completed actions.

Dashboard Widget: Displays all user's incomplete actions on the main dashboard. Shows: Date Assigned, Assigned-by (Created By), Related-To Entity. Sorted descending by date (oldest assignments first to surface urgent items).

Widget Interactions:

• Click action to open view modal
• Mark complete button toggles status
• Click related entity to navigate to record
• Widget refreshes on every page load

Notification Badge: Main navigation shows a badge count of incomplete actions. Updates in real-time when actions are created or completed.

Notification Dropdown: Bell icon in upper right shows notification history. Clicking a notification navigates to Browse All screen with "Actions Assigned to Me" filter applied.

Notification Triggers:

• Action created and assigned to current user
• Action reassigned to current user
• Action due date approaching (48-hour warning)
• Action due date passed (overdue notification)

Edit Rights Model:

• Notes: Only creator can edit or delete
• Actions: Creator OR assignee can edit; only creator can delete

Edit Form Fields: All fields can be updated except Created By and Created Date/Time. Last Modified Date and Modified By are automatically updated.

Delete Behavior: When a note/action is deleted, it is removed from the database. A soft-delete audit log is maintained for compliance (not visible in UI but available for compliance queries).

Attachment Edit/Delete: Users can add, view, or remove attachments from the edit form. Removing an attachment does not delete the associated note/action.

Attachment Support (ABC-1919): Users can attach images and documents to notes/actions during creation or edit.

Supported File Types: PNG, JPG, PDF, DOCX, XLS (configurable; default to image formats)

File Size Limits: Maximum 10 MB per file; maximum 5 files per note/action (configurable)

Upload Flow:

• User clicks "Add Attachment" in form
• Native file picker opens
• User selects file(s)
• File uploads asynchronously (progress bar shown)
• Thumbnail/preview displayed for images
• Attachment name editable

View/Download: In view modal, attachments display with preview (images) or icon (documents). Users can download or open in new tab.

Virus Scanning: All uploaded files are scanned for malware. If detected, upload is rejected with user-friendly error message.

Key Rule: When an action is marked complete, it displays as Type="Note" throughout the interface, but retains all original metadata (Assigned To, Due Date, Completed Date).

Why This Matters: Completed actions must appear in historical records and audit trails but should not appear in active task lists by default. This dual identity (Type="Note" display + Action metadata retention) creates audit trail completeness.

Common Gotchas:

• Filter Confusion: QAs often expect completed actions to appear when filtering by "Type=Note". They will appear as notes but can be distinguished by the presence of Completed Date and Status="Complete".
• Edit Rights Post-Completion: Creator can still edit completed actions; assignee cannot. This is different from most task systems and must be validated.
• Reopening: Creator can theoretically reopen a completed action by changing Status back to Open. Ensure Last Modified Date and Modified By are updated.
• Dashboard Default: The dashboard widget shows only OPEN actions by default, not completed. Users should not see completed actions cluttering their task list.

Key Rule: When creating a global note/action on multiple records (from Selective Reporting), if creation fails on some records, the system does NOT roll back successful records. Instead, it reports a summary and allows manual retry.

Why This Matters: Global notes are often created on 100+ records. Rolling back due to a single permission failure on one record would negate all progress, frustrating users. Partial success with reported failures is more practical.

Common Gotchas:

• Permission Failures Not Obvious: If user lacks Level 1+ permission on a specific company, the global note creation may silently fail on that record. The summary report (e.g., "Created on 99, failed on 1") must be clear.
• Duplicate Detection per Record: If a duplicate action already exists on record #50 of 100, creation succeeds on 1-49 and 51-100 but fails on 50. The error must specify which record(s) failed.
• No Rollback, But Audit Trail: All attempted creations are logged. Failed attempts show in audit with reason (permission denied, duplicate detected, etc.).
• User Retry Burden: Users must manually retry failed records. QA should validate that failed record list is exportable or easily identifiable for manual action.

Key Rule: The system prevents creation of duplicate actions on the same record with identical parameters (same category, type, assignee, due date). A warning is displayed if user attempts duplicate creation.

Why This Matters: Global notes create 100+ records quickly. If user accidentally runs the same global note create twice, duplicates would pollute the system. Prevention is critical.

Common Gotchas:

• Identical Parameters Definition: What exactly constitutes "identical"? Related To Type + Related To Record ID + Category + Type + Assignee + Due Date? Text can differ and still be considered duplicate? QA must verify exact matching logic.
• User Intent Ambiguity: User might intentionally create two "Follow-up Call" actions due tomorrow on Company #50 (e.g., one for Sales, one for Support). System preventing this could be frustrating. Warning vs hard block matters.
• Warning Message Clarity: The warning should show the existing action and ask "Create duplicate anyway?" User should be able to confirm override if intentional.
• Timing Window: If user creates action, closes browser, later tries to create again, is it still detected as duplicate? Yes, because it checks database, not session state.

Key Rule: Global notes/actions automatically prepend origin prefix (e.g., "[Selective Reporting]") to the text. This is not done in Browse display only—it's stored in the database.

Why This Matters: When a user views a note on a company record, they can immediately see that it came from a global action, aiding traceability and preventing confusion about authorship.

Common Gotchas:

• Text Length Impact: If user enters 500-char note text and prefix adds 25 chars, total is 525. Check database field max length (likely 1000 chars); should be sufficient but QA should verify.
• Search/Filter Behavior: If user searches for their exact note text in Browse, will they find it? Yes, because search should be substring match. But exact phrase match might not find it due to prefix. Test both.
• Editing Behavior: If user edits a global note later, should the prefix be editable? Likely NO; prefix is immutable. Only the text portion after the prefix can be edited. QA should verify UI prevents prefix editing.
• Admin-Configurable Prefix: Is the prefix "[Selective Reporting]" hard-coded or admin-configurable? If configurable, test admin update and verify new globals use new prefix; old globals retain old prefix.

Key Rule: Note Date defaults to current date but can be back-dated (set to any past date). This field is REQUIRED; notes cannot be created without a date.

Why This Matters: Users might record historical notes (e.g., "We discussed this on Jan 5, today is Feb 1, adding note retroactively"). Back-dating supports accurate historical record-keeping.

Common Gotchas:

• Far-Past Dates: Can user set note date to 1999? 1970? System should validate but QA should check: are there reasonable bounds (e.g., not before company creation date)? Or is any date allowed?
• Future Dates: Can user set note date to tomorrow? Next month? Likely YES for planning purposes. Test both past and future edge cases.
• Created Date vs Note Date: These are different. Created Date is auto-timestamp (today), Note Date is user-editable. QA must distinguish and test both fields.
• Sort Impact: Browse default sort is by Date (Note Date, not Created Date), descending. Back-dated note will appear in its historical position, not at top. Test sort correctness.
• Filter Impact: If user filters by date range (Jan 1 - Jan 31), back-dated note to Jan 15 should appear even if created today. Verify filter uses Note Date, not Created Date.

Key Rule: Action Checklists include predefined actions with future date offsets (e.g., "+1 day", "+7 days"). When attached to a record, the system calculates each action's due date as: today + offset.

Why This Matters: Checklists standardize task timing. For onboarding, you might want Call on day 1, Email on day 3, Review on day 7. Offsets automate this.

Common Gotchas:

• Weekend/Holiday Handling: If user attaches checklist on Friday (+1 day offset), is due date Saturday or Monday? System should have rule (skip weekends, skip holidays, or allow). QA should verify documented behavior and test edge cases.
• Offset 0 Days: Can an action have "+0 days" offset (due today)? Should be allowed. QA should test and verify display.
• Negative Offsets: Can admin create action with "-5 days" offset? Likely not (past-due task doesn't make sense). Test admin validation.
• Timezone Impact: If admin is in PT and creates checklist, and user attaches in ET, does date calculation account for timezone? Likely uses server time. QA should verify offset calculation uses consistent timezone (likely server/UTC).
• Bulk Attachment: If user attaches same checklist to 10 companies on different days, each attachment calculates offset from its own day. Friday attachment gets different dates than Monday attachment of same checklist. Verify each attachment calculates independently.

Key Rule: Access to notes/actions is driven by parent module permissions (Level 1+). No separate N&A permission group. If user loses access to Company A (permission downgrade), can they still view/edit notes on Company A? No—permission inheritance is strict.

Why This Matters: Prevents unauthorized access to company/individual data via notes back-door. If user is removed from company team, notes visibility should revoke immediately.

Common Gotchas:

• Existing Notes Post-Permission-Loss: If User A had permission, added note to Company X, then permission revoked, can User A still see the note they created? Behavior varies: some systems allow creator to always see created content (soft delete); others enforce strict permission. QA must verify documented behavior and test.
• Edit Rights Conflict: User B (assignee) may have no permission to Company X but was assigned an action on Company X by User A (who had permission). Can User B edit the action without company permission? Likely NO; action edit should require company permission. Test and verify.
• Level 1 Boundary: The rule is "Level 1+" required. What is Level 0? Can Level 0 users view notes at all? Likely no view access if Level 0. Test Level 0 user permission boundary.
• Inherited Permissions: If Company permission is inherited (via Team membership), does Note/Action permission inherit too? Yes, permission model is unified. QA should test with inherited permission scenario.

Key Rule: The Browse All screen default filter was changed from "Show All Actions" to "Actions Assigned to Me". When user navigates to Notes & Actions from main nav, they see only their own incomplete actions by default.

Why This Matters: User-centric default reduces cognitive load. Most users are interested in their own tasks, not a firehose of all 500 org actions. This change aligns with task management best practice.

Common Gotchas:

• Regression Risk High: This is a user-facing change. Old users expecting to see all actions may be surprised. Documentation must be clear. QA should test with diverse user personas.
• Filter Persistence: If user changes filter (e.g., shows all actions), then navigates away and returns to Notes & Actions, does default filter reset to "Actions Assigned to Me"? Likely YES (apply default on page load). But if user saved custom filter, does saved filter override default? QA should test filter persistence logic.
• Notification Click-Through: When user clicks notification in bell dropdown, they navigate to Browse with "Actions Assigned to Me" filter. Verify this is consistent behavior.
• Completed Actions Excluded: Default filter should show only OPEN actions assigned to me, not completed. QA should verify completed actions are excluded from default filter.
• No Personal Actions: Edge case: User A has no actions assigned to them. Browse with default filter shows empty state. Verify message is helpful (e.g., "No actions assigned to you") not confusing.

User Persona: Sarah, Chapter Manager (Level 1+ on 50+ Companies)

Goal: Onboard new company using standardized action checklist and track completion.

Scenario Steps:

1. Sarah navigates to Company "ABC Corp" detail screen
2. Clicks "Attach Checklist" button
3. Selects "New Company Onboarding" checklist from dropdown
4. System auto-assigns all actions to Sarah (default) with calculated due dates
5. Sarah confirms. 5 actions created: Kickoff Call (due +1 day), Initial Documents (due +3 days), Needs Assessment (due +5 days), Proposal Review (due +10 days), Contract Finalization (due +15 days)
6. Sarah completes Kickoff Call, marks action complete via Browse screen
7. Dashboard widget updates, Kickoff Call no longer appears in "incomplete actions"
8. Sarah reopens Browse, applies custom filter "Actions Assigned to Me on ABC Corp". Verifies 4 remaining actions
9. Sarah reassigns "Proposal Review" to colleague Bob
10. Bob receives notification, sees action in his "Actions Assigned to Me" default filter
11. Sarah exports Browse results to PDF for stakeholder meeting

Key Validations: Checklist attachment, date offset calculation, action completion flow, dashboard widget refresh, filter accuracy, export functionality, reassignment notifications.

Test Coverage: Single record workflow, CRUD operations, multi-user collaboration, admin features (checklist), notification system.

User Persona: Marcus, National Operations Manager (Level 1+ on all Companies)

Goal: Cascade policy update actions to all companies in Western region.

Scenario Steps:

1. Marcus runs Selective Reporting: "All Active Companies where State in [CA, WA, OR]". Results: 45 companies
2. Selects all 45 companies in result set
3. Clicks "Create Global Action" button
4. Fills form: Category="Policy Update", Type="Training Required", Text="Complete new compliance training module X by deadline", Assigns to "Regional Manager" roles (mapped per company), Due Date="Q2 End"
5. Clicks "Create on All Selected"
6. System displays progress bar. 44 actions created successfully, 1 fails (company #25—Marcus lacks permission). Summary: "Created 44 actions, Failed 1"
7. Marcus manually creates action on company #25 (or verifies permission and retries)
8. All regional managers receive notifications about new compliance training actions
9. Marcus navigates to Browse, filters by Category="Policy Update", verifies all 45 actions exist with prefixed "[Selective Reporting]" text
10. Marcus adds note to one company (Company A) with supplementary detail
11. Marcus exports filtered results (45 actions) to Excel for tracking

Key Validations: Global action creation, partial failure handling, prefixed text, bulk filtering, permission inheritance, export with large dataset.

Test Coverage: Selective Reporting integration, error handling, multi-user notifications, audit trail accuracy.

User Personas: Lisa (Creator), Tom (Assignee), Jordan (Other Staff)

Goal: Validate that edit/delete permissions are enforced correctly.

Scenario Steps:

1. Lisa creates action "Follow-up Call", assigns to Tom, due next Monday
2. Lisa attempts to edit the action. SUCCESS (creator can edit)
3. Lisa clicks delete. SUCCESS (creator can delete)
4. Lisa restores from undo or recreates the action (for next test step)
5. Tom (assignee) attempts to edit the action. SUCCESS (assignee can edit)
6. Tom changes assignee from self to Jordan
7. Tom attempts to delete the action. FAILURE (only creator can delete)
8. Jordan (new assignee) attempts to edit the action. SUCCESS (assignee can edit)
9. Jordan changes status to "Complete"
10. Lisa (creator) attempts to edit completed action. SUCCESS (creator always can edit)
11. Tom (former assignee) attempts to edit completed action. FAILURE (no longer assignee, cannot edit)
12. Lisa deletes completed action. SUCCESS (creator can always delete)

Key Validations: Creator-only delete enforcement, creator/assignee edit rights, assignee change impact, completed action permission inheritance, no orphaned records.

Test Coverage: Permission model, RBAC enforcement, state transitions (open -> complete), audit trail.

User Persona: Rebecca, Account Manager (retrospective documentation)

Goal: Create back-dated notes to document historical interactions accurately.

Scenario Steps:

1. Rebecca opens Company X record on Jan 31
2. Clicks "Add Note"
3. Sets Note Date to "Jan 15" (back-date 16 days)
4. Enters text: "Discussed renewal terms. Client prefers 3-year contract."
5. Saves note
6. Rebecca navigates to Browse All, filters by "Date = January"
7. Back-dated note appears in Jan 15 position (not at top, respecting date)
8. Rebecca then creates current-date note (Jan 31): "Follow-up call scheduled"
9. Browse default sort (descending): Jan 31 note appears above Jan 15 note (newest first)
10. Rebecca exports notes for Company X. Verifies both notes export with correct dates
11. Rebecca filters by date range "Jan 10 - Jan 20". Verifies Jan 15 note appears, Jan 31 note does not

Key Validations: Back-date support, date field acceptance (past dates valid), sort order respects Note Date, filter uses Note Date not Created Date, export date accuracy.

Test Coverage: Date handling, filter accuracy, data integrity, historical documentation support.

Run before every release to catch critical regressions.

• Create single note on Company record. Verify saved and visible in Browse
• Create single action on Individual record. Assign to another user. Verify visible in Browse with correct assignee
• Mark action complete via Browse. Verify status changes to "Complete" and Type displays as "Note"
• View Browse default filter. Verify "Actions Assigned to Me" is default (not "All Actions")
• Edit action due date. Verify Last Modified Date updates. Verify due date is no longer called "Action Date"
• Delete note (as creator). Verify delete succeeds and note disappears from Browse
• Try to delete action (as assignee, not creator). Verify delete fails with permission error
• Check Dashboard widget. Verify incomplete actions display. Verify quick-complete works
• Check notification badge on main nav. Verify count accurate (number of incomplete actions assigned to me)
• Export Browse results to Excel. Verify file downloads and contains expected columns (Type, Related To, Assigned To, Due Date, Status, etc.)

Validate creation and edit flows after UI or form changes.

• Create note: verify all form fields present (Related To Type, Related To, Note Date, Category, Type [optional], Text, Attachment). Verify defaults apply (Note Date = today, Created By = current user)
• Create action: verify additional fields present (Assigned To, Due Date, Status, Category, Type). Verify Assigned To defaults to Created By. Verify Status defaults to "Open"
• Test Note Date back-dating. Create note with Date = 30 days ago. Save. Verify Browse shows note in historical position (sorted by Note Date, not Created Date)
• Test Note Type optional behavior (per ABC-1960). Create note without selecting Type. Verify note saves and no error
• Test attachment upload. Upload PNG image (5 MB). Verify thumbnail displays. Try upload 15 MB file. Verify rejection with file size error
• Edit note: change text, date, category. Verify save succeeds. Verify Last Modified Date updates. Verify Modified By = current user
• Edit action: change assignee, due date, status. Verify save succeeds. Verify all fields update correctly. Verify Last Modified Date updates
• Try edit action as assignee (not creator). Verify edit succeeds if assignee. Change back to original assignee
• Test edit action to "Complete". Verify Status changes to Complete, Completed Date auto-fills, Type displays as "Note" in Browse
• Test reopen completed action (edit Status from Complete to Open). Verify succeeds. Verify Completed Date clears (or persists for audit—verify documented behavior)

Validate global note/action creation and action checklists.

• Run Selective Reporting (Companies). Select 10 companies. Create global note "Test Note"
• Verify global note created on all 10 with prefixed text "[Selective Reporting] Test Note"
• Verify prefixed text stored in database (Edit note, confirm prefix is immutable)
• Create global action with due date. Verify all 10 actions created with same due date, assigned to current user
• Test partial failure: Run Selective Reporting with 10 companies. User lacks permission on company #5. Create global action. Verify 9 created, 1 failed. Verify summary message shows failure details
• Test duplicate prevention: Create global action on 10 companies. Immediately retry. Verify warning "Action already exists on some records". Confirm override to create duplicates or cancel to prevent
• Admin: Create Action Checklist "Test Checklist" with 3 actions (offsets +0, +3, +7 days). Assign to Company module
• User: Navigate to Company record. Click "Attach Checklist". Select "Test Checklist". Verify 3 actions created with correct due dates (today, +3, +7)
• Admin: Copy the checklist. Verify copy successful, original unchanged. Assign to Individual module. Verify copy shows as separate checklist
• Admin: Disable the checklist. Verify disabled checklist no longer appears in "Attach Checklist" dropdown
• Test global action assigned to "Regional Manager" role. Verify action assigned correctly per role mapping (different regional managers for different companies)

Validate Browse screen, filters, sorting, pagination, and export.

• Navigate to Browse All. Verify default filter applied: "Actions Assigned to Me" (not "All Actions")
• Verify default sort: Type ascending (Actions above Notes), then Date descending (newest first)
• Create 15+ notes/actions to test pagination. Verify pagination controls present. Verify page size selector (25, 50, 100 items)
• Filter by Type="Action". Verify only actions displayed (notes hidden)
• Filter by Type="Note". Verify only notes displayed (actions hidden). Verify completed actions appear as Type="Note" and are visible in this filter
• Filter by Related To Type="Company". Verify only company notes/actions displayed
• Filter by Related To (search "ABC Corp"). Verify search returns only records matching company name
• Filter by Assigned To="[Specific User]". Verify only that user's actions displayed
• Filter by Due Date range "Jan 1 - Jan 31". Verify only actions with due date in range displayed. Verify date uses Due Date field (renamed from Action Date)
• Combine multiple filters: Type="Action" AND Assigned To="Me" AND Due Date < today. Verify all filters apply (intersection, not union)
• Verify sort options work: sort by Due Date ascending/descending, Created By A-Z, Last Modified descending. Verify default sort (Type, then Date) still works
• Export filtered results (5-10 records) to Excel. Verify all visible columns exported (Type, Related To Type, Related To Name, Created By, Assigned To, Date, Due Date, Status, Last Modified, Text). Verify Excel formatting readable
• Export to PDF. Verify PDF generates successfully, contains expected data, formatting clear
• Test "Actions Assigned to Me" filter includes completed actions. Filter by Status="Complete". Verify completed actions visible. Verify default filter excludes them (shows only Open)

Validate permission inheritance, edit/delete boundaries, and access control.

• User with Level 0 (no permission) tries to create note on Company. Verify rejected with "Permission denied"
• User with Level 1+ creates note on Company. Verify created successfully. Verify Level 0 user cannot see note in Browse
• Admin downgrades user from Level 1+ to Level 0 on Company. User refreshes Browse. Verify note no longer visible
• Admin upgrades user back to Level 1+. User refreshes Browse. Verify note reappears
• Creator creates action. Creator can edit: Verify SUCCESS. Creator can delete: Verify SUCCESS
• Assignee (not creator) tries to edit action. Verify SUCCESS (assignee can edit)
• Assignee tries to delete action. Verify FAILURE (only creator can delete)
• Other user (neither creator nor assignee) tries to edit action. Verify FAILURE or restricted access depending on permission model
• Creator marks action complete. Assignee tries to edit completed action. Verify FAILURE (assignee cannot edit completed actions)
• Creator can edit completed action. Verify SUCCESS (creator can always edit, even after completion)
• Test permission inheritance from Team membership. User added to Company Team (inherits Level 1+). Verify can view notes on that Company. User removed from Team. Verify notes no longer visible
• Test "Assigned To" permission: User assigned action on Company they have no Level 1+ permission on. Verify user cannot view or edit action (permission-driven, not assignee-driven access)

Validate dashboard widget, badge count, and notification system.

• Create 5 open actions assigned to current user. Navigate to Dashboard. Verify widget displays all 5 actions
• Verify actions sorted by age (oldest first, not newest)
• Verify each action shows: Date Assigned, Assigned-by (Created By), Related-To Entity
• Click action in widget. Verify view modal opens
• Use "Quick Complete" button on action in widget. Verify status changes to Complete
• Refresh Dashboard. Verify completed action no longer displays (widget shows only open)
• Verify badge count on main nav Notes & Actions menu. Should show number of incomplete actions assigned to me
• Create new action assigned to me. Verify badge count increments immediately (or on next page load)
• Mark action complete. Verify badge count decrements
• Check bell icon / notification dropdown. Create action assigned to me. Verify notification appears in dropdown
• Click notification. Verify navigates to Browse with "Actions Assigned to Me" filter applied
• Test overdue notification: Create action with due date = yesterday. Verify system sends "overdue" notification or indicates overdue status
• Test due-soon notification: Create action with due date = tomorrow. Verify system may send "due soon" notification (48-hour warning, if feature exists)
• Test reassignment notification: Create action assigned to User A. Change assignee to User B. Log in as User B. Verify notification received about reassignment

Validate admin screens for managing categories, types, and checklists.

• Admin: Navigate to Admin > Manage Categories. Verify list of existing categories displays
• Admin: Create new category "Test Category". Save. Verify appears in list and is Enabled by default
• User: Create note with new category. Verify category selectable and saves correctly
• Admin: Disable "Test Category". Verify no longer appears in category dropdown for new notes
• Admin: Re-enable category. Verify reappears in dropdown
• Admin: Delete category (if allowed). Verify deletion succeeds or shows error if in-use
• Admin: Manage Types. Create type "Test Type" with description and optional prefix "[TT]". Save
• User: Create action with new type. Verify type selectable. Verify prefix displays on Browse if configured
• Admin: Edit type. Change prefix to "[TEST]". Save. Verify new actions use new prefix; old actions retain old prefix
• Admin: Manage Checklists. Create checklist "Test Onboarding" for Company module with 3 actions (+0, +2, +5 days). Save
• Verify checklist enabled by default. User can attach to company record
• Admin: Copy checklist. Verify copy created with new name. Verify original unchanged. Assign copy to Individual module
• User: Try to attach "Test Onboarding" to Company (should work). Try to attach to Individual (should fail or not show copy). Try to attach copied checklist to Individual (should work)
• Admin: Disable original checklist. Verify no longer available for attachment. Copied checklist still available (if different module)
• Admin: Edit checklist. Modify action due date offsets. Save. Verify new attachments use new offsets; old attachments unaffected